home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19950528-19950726
/
000321_news@columbia.edu_Tue Jul 11 09:08:36 1995.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
5KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA08197
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 12 Jul 1995 06:16:07 -0400
Received: by apakabar.cc.columbia.edu id AA02704
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 12 Jul 1995 06:16:04 -0400
Path: news.columbia.edu!panix!news.mathworks.com!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: HELP!! kermit not work with TCP/IP ..
Message-Id: <1995Jul11.150836.55845@cc.usu.edu>
Date: 11 Jul 95 15:08:36 MDT
References: <3tu058$hlf@news.cais.com> <1995Jul11.093633.55816@cc.usu.edu> <3tuesm$o4d@news.iastate.edu>
Organization: Utah State University
Lines: 68
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3tuesm$o4d@news.iastate.edu>, zollner@iastate.edu writes:
> In <1995Jul11.093633.55816@cc.usu.edu>, jrd@cc.usu.edu (Joe Doupnik) writes:
>> Yes, you don't have the lan adapter handler (ODI, Packet Driver)
>>stuff configured properly. Please review the networking notes distributed
>>with MSK and follow the examples carefully. If you are using ODI then
>>pay very careful attention to syntax because there is no originality
>>permitted in net.cfg.
>> Joe D.
>
> Is there an example for how to use a third-party TCP/IP stack (for example
> from IBM)? The only third-party stack mentioned is from FTP Inc, and that
> needs an extra switch. Is there an (undocumented) switch for the IBM
> TCP/IP stack?
--------------------
Ok, let's try this again.
There are, I believe, two (2) IBM TCP/IP stacks: for OS/2 and for
DOS, or in other words protected mode and real mode. Protected mode clients
stand a chance of using the protected mode stack, if built right, but not
the real mode one. And similarly, real mode clients stand a chance of using
the real mode stack, if built right, but not the other one.
End of part one.
Begin part two, "if built right."
These stacks, and similarly for almost all commerical stacks, do
not provide an Int 14h interface or similar by themselves. They have a
proprietary set of calls (and usually an interrupt) which joins them with
matching library modules built into the client application. The library
is also proprietary. The client/lib to/from stack transfer mechanism is
proprietary. The top end of the library usually provides a BSD sockets
interface for the client software. That software must be linked (.obj
modules, Link command) with the library to be a functional executable.
Now for the discussion and conclusions section, long.
MS-DOS Kermit cannot be built holding commercial/proprietary
libraries, and it cannot shield vendors from exposing all source code
involved. MS-DOS Kermit is a real mode program, with Windows/DV/OS2
smarts but not dependent on them. It is not a protected mode program,
to restate the obvious.
MS-DOS Kermit works well with FTP Inc's DOS TCP/IP offerings,
because we want it to be so. But that means we go through the FTP TNGLASS
Int 14h module provided by FTP, even though I have their library material
(complements of FTP Inc, with much thanks by the way). MSK works with Novell's
LWP/DOS stack, by design, ditto. And with Beame and Whiteside's TCP/IP
suite, by design, and ditto. These are all DOS/real mode stacks. Each
involves a vendor provided interface module which is publically documented
and requires no vendor modules within Kermit. B&W has a full function suite
available via an interrupt which MSK uses.
It's not that we (Kermit) are being picky, but we are dependent on
contributions to make progress with commercial offerings (else out of my
personal pocket). The above vendors have been most generous with assistance.
We cannot make the Kermit code dependent on anyone's commercial material,
both because folks need to be able to build or redistribute Kermit without
third party copyright/license restrictions and their libraries, and because
we (Kermit) cannot protect proprietary material from public view in the
distribution products. That means we can't do some nifty things with these
nice TCP suites, but that's the way it is right now. But we do work with them
in other ways, and their customers are the beneficiaries (which is the whole
idea).
MS-DOS Kermit works with other protocol stacks via public interface
mechanisms: DECnet's CTERM and LAT, Novell's NASI/NACS, Meridian Technology's
SuperLAT, Interconnections TES, variations on NetBIOS, etc.
If your (IBM or whatever) TCP/IP stack provides a real mode Int 14h
or similar interface module then MSK should work with it out of the box.
If it does not then sys$error:does_not_work.
I hope this clarifies the situation a little.
What do I use with OS/2? Good question. Answer: a second Ethernet
adapter, ODI or Packet Driver (depending on what kind of testing I'm
doing), and MSK in a DOS window. I also use C Kermit for OS/2, and IBM's
own TCP/IP material (stack and applications taken as a whole).
Joe D.